1. Field of the Invention
The present invention generally relates to logic simulation of electronic systems, and more particularly to a system for debugging a heterogeneous design in a co-emulation or co-simulation environment.
2. Description of Related Art
An IC design typically organizes the logic blocks of an integrated circuit (IC) into a set of modules that communicate with each other, and at various stages of the development process an IC design models the modules at varying levels of abstraction. A logic simulator running on a computer workstation compiles a circuit design into executable code and then executes that code to simulate the behavior of the circuit in response to a user-defined pattern of input signals. During the simulation, the logic simulator saves data representing the succession of state changes of various signals of the IC in a value change dump (VCD) file. A user can then employ a debugger accessing the VCD file to debug the circuit design based on the simulated signal behavior.
Since saving data representing the behavior of every signal of a simulated circuit in a VCD file takes too much time, a user will normally program the logic simulator to save data representing behavior of only a selected subset of the circuit's signals such as, for example, the input and output signals of each module. If the user determines during debugging that a particular module of interest has a design defect and wants to know how the internal signals of that module behaved during the simulation, the user can rerun the simulation, telling the logic simulator to save data representing the behavior of those internal signals. Since the module of interest receives signals from other modules, it is necessary to re-run the simulation of the entire circuit, not just the module of interest. Thus a replay simulation can require as much processing time as the original simulation.
One way to reduce processing time for a replay simulation is to replace the slow executing models of various circuit modules with a fast executing script that simply reproduces the input signals to the module of interest. As illustrated in FIG. 1, Synopsys Inc. markets a Verilog Compiled Logic Simulator (“VCS”) including a utility ‘vcat’ 10 for generating Verilog and very high-level design language (VHDL) scripts 12 from a value change dump VCD file 14. When the logic simulator saves the value changes of input signals and output signals of a simulated circuit module, the vcat utility 10 can convert those saved values to executable high-level language (HDL) code (a “script”) 12, that the logic simulator can execute in lieu of the original code of the module during simulation re-runs if all the conditions stay the same during the re-runs. A configuration file (vgen.cfg) 12 contains a module header and port declarations (a module interface definition), an indication as to whether testbench generation or module generation is to be performed and the hierarchical name of the module instance. Thus if the user is interested in investigating internal behavior of a particular module of a simulated circuit, the user can run a re-simulation of a particular module more quickly by using vcat output scripts to represent other portions of the simulated circuit.
Depending on usage, vcat can generate a testbench for a specified module instance, or to generate a module to mimic the behavior of a specified module instance. In the first approach, value changes of the input signals to a module instance are computed by the generated HDL code and used to drive those input signals during subsequent simulations. In the second approach, value changes of output signals of a module instance are computed by the generated HDL code and used to drive those output signals during subsequent simulations. The first approach (“test bench generation”) allows the user to preserve the code of the designated module of interest while replacing the rest of the system with the generated HDL code. The second approach (“module generation”) allows the user to replace a designated module instance with the generated HDL code and preserve the rest of the system. The test bench or module generation supports only modules that do not have bi-directional “inout” ports.
A Carbon Design Systems, Inc. tool “Model Studio” can compile register transfer level (RTL) code into high-speed software models. Another Carbon Design Systems, Inc tool provides a “Replay Plug-In” for accelerating the runtime speed of a virtual platform and enabling interactive software debugging that runs on the virtual platform. These “carbonized” high-speed software models save value changes in a file during the first simulation run. On subsequent runs, the carbonized modules use the values saved in the file as long as the input values provided as stimulus to those models remain unchanged from the first simulation run. The carbonized models are capable of detecting differences in stimulus, and automatically switching to actually evaluating the model in full when necessary to generate the correct outputs. During the first simulation, when software is executing on Carbon Models, the Carbon Models record incoming bus traffic and responses and save the models' state information periodically at “checkpoints”. In subsequent iterations, the Carbon Models replay their saved responses to the system at very high-speed. The replay system monitors the model stimulus and detects any differences from previous runs. If there is a change, a full Carbon Model is substituted for the Replay Model guaranteeing that the simulation can execute new code paths with the hardware's true behavior. The high-performance Replay Model enables interactive software debugging, while maintaining hardware accuracy.
A circuit design can incorporate pre-designed “core” modules into an IC design. Referring to FIG. 2, U.S. publication number 20060101309 filed May 11, 2006 by Mohiuddin et al. teaches that when a circuit designer wants to incorporate a core described in RTL code into a circuit containing other modules, the core designer provides an encrypted version 106 of the RTL code within a simulation environment 100 while the circuit designer provides models for the other circuit modules 108. When the circuit designer runs a simulation of encrypted core 106, he cannot inspect the internal functioning of the encrypted core 106 to determine why the encrypted core may not have behaved as expected. The circuit designer therefore cannot debug the overall design with respect to the functions of the encrypted core 106 without assistance of the core designer, since only the core designer can examine the interior behavior of the unencrypted core 104. To avoid having to disclose details of the other modules 108 to the core designer, the circuit designer can use a pattern recorder 110 (a simulation tool or utility) within simulation environment 100 to record input stimuli provide by the other modules 108 to encrypted core 106 through an input/output (I/O) wrapper 114, an HDL module that defines the I/Os of the encrypted core 106 and allows the core designer to view the top-level I/Os of the encrypted core 106.
Pattern recorder 110 also records output results generated by the encrypted core 106 due to the input stimuli. A record clock 136 clocks sampling and recording of the input stimuli 112, a check clock 138 clocks sampling and recording of the output 116, and a system clock 140 clocks modules 108 and encrypted core 106. The recorded input stimuli are saved within a flag file 118 and an input pattern file 120, and the recorded output results are represented within the output pattern file 122. The circuit designer provides files 118,120 and 122 to the core designer to assist in the troubleshooting or debugging of the circuit design with respect to the functions of encrypted core 106 in another simulation environment 102 employed by core designer.
The core designer's simulation environment 102 includes a pattern player 124, a pattern checker 126 (additional simulation tools or utilities), and the unencrypted core 104. The pattern player 124 receives the flag file 118 and the input pattern file 120. With these files 118 and 120, the pattern player 124 generally recreates the input stimuli 112 (recreated input stimuli 128) during simulation within the company's simulation environment 102. The pattern player 124 supplies the recreated input stimuli 128 to the core 104. The core 104 generates output results (output 130) in response to the recreated input stimuli 128. Pattern checker 126 compares output 130 with output pattern file 122 to find any mismatches 132 between the output results from the two simulation environments 100 and 102. Any such mismatches 132 are presented to a user of the company's simulation environment 102 to investigate the cause of the mismatch. Additionally, the pattern checker 126 supplies waveforms of the output 130 and the output pattern file 122 to any appropriate waveform viewer 134.